http://www.boost.org/doc/libs/1_46_1/doc/html/boost_asio/example/multicast/receiver.cpp
^Implicitly threaded

http://www.boost.org/doc/libs/1_46_1/doc/html/boost_asio/example/multicast/sender.cpp



Maybe only the master should have a known address. Every would-be client could attempt to
establish a TCP connection at a regular interval (and try to re-establish them as needed)

The master would then identify the role each client performs through a handshake and become
the nexus for all communication. This would prevent construction engines from needing to
know about grammar-checking components, because they could route requests through the
master, but the downside is that the master may become flooded by requests from weaker
productions, which it would need to buffer (and it would need to announce high scores
regularly). TCP emmission latency may also be a factor.

If the production engines are instructed to send data no more frequently than once every
X milliseconds, then they could use the additional time to iterate on candidate productions
more than they would if just blindly constructing, but the lost opportunity cost may be
significant.

Another possibility, and one likely to work better, would be for the master to announce
relevant (all?) resources to all connected entities so that they can communicate directly.
Each resource could announce activity internally to try to keep from becoming overloaded, but
no global load-data would be known, so each resource would need to use absolute terms like
"less than 50%" or "refusing data" signals.

Use TCP_NODELAY, but assemble full structures in memory. (Should be easy if using JSON)
Alternatively, use TCP_CORK to stop and start the flow of data.